Access management is highly desirable in connection with granting access to a digital resource such as a digital service or digital content, which may include digital audio, digital video, digital text, digital data, digital multimedia, etc. The resource can be the aforementioned content or the like, a server or the like having a library of content or the like, or any other or digital repository of information that a user might wish to access such as for example an electronic mail server, a gaming server, a network access server or point, etc. Likewise, the resource can be a service, such as a printer, a compiler, a renderer, or the like.
Typically, in an access management context, a requestor is granted access to a resource upon presenting a request with a credential identifying the requester. For example, the credential may comprise a digital certificate issued to and identifying the requestor. In any event, the credential is typically issued to the requestor by an issuer that is known to and trusted by the resource. For example, within the context of an organization, the resource may be a data file managed by a data server and the issuer may be an identity server set up by an administrator to provide an identifying credential to each member of the organization.
Upon satisfying itself based on the credential and perhaps other information that the requestor is indeed entitled to access to the requested resource, such resource then provides such access. For example, if the request is for a data file from the resource, the resource provides such data file, and if the request is to review information available from the resource, the resource allows the requestor to in fact review such information.
Notably, in at least some instances the resource provides data to the requester. If so, the resource may choose to encrypt the data according to a format that allows the requestor to decrypt same, but not others. For example, it may be that the presented credential of the requestor is a digital certificate that includes a public key associated therewith, and the resource encrypts the provided data according to the public key of the presented credential. Thus, the requestor may apply a corresponding private key associated with the digital certificate to the encrypted data to reveal same.
Also notably, the resource may choose to attach terms and conditions to the encrypted data that the requestor must abide by. If so, and again presuming that the presented credential of the requestor is a digital certificate that includes a public key associated therewith, the resource may encrypt the provided data according to a selected symmetric key, encrypt the symmetric key according to the public key of the presented credential, and place the encrypted symmetric key and the terms and conditions in a digital license. Thus, the requestor may apply the corresponding private key associated with the digital certificate to the encrypted symmetric key of the license to reveal same, and then apply the decrypted symmetric key to the encrypted data to reveal same, presuming of course that the terms and conditions in the license so allow.
Typically, the resource is presumed to have prior knowledge of the requestor, or at least the administrator that provides the credential of the requestor, and thus provides access to the requestor based on same. For example, it maybe that the resource follows a rule that only allows access to a particular set of requesters known to the resource, or that only allows access to requesters that provide a credential from a particular administrator already known to the resource. If a requester is not within such a group, then, such requestor is not provided with access by the resource according to the rule.
However, situations exist where the requestor should be provided access even though not previously known to the resource and not within the rule followed by the resource, either as being from a particular set of requestors or having a credential from a particular administrator. For example, a resource within an organization ABC may be set up to follow an access rule that provides access to all employees from ABC, as signified by each such employee having an appropriate credential from an ABC administrator. Nevertheless, it may be that ABC has engaged contractors from XYZ and such XYZ contractors should also have access to the resource.
In the prior art, then, the XYZ contractors could be given access to an ABC resource by giving each such XYZ contractor an ABC credential from the ABC administrator. However, the ABC administrator may be loathe to do so, especially if such an ABC credential could have the effect of the XYZ contractor being treated like an ABC employee, or could allow the XYZ contractor to improperly access another ABC resource.
As an alternative, and also in the prior art, the XYZ contractors could be given access to an ABC resource by altering the access rules for that ABC resource. For example, such access rules could be altered to allow the ABC resource to provide access to a particular set of XYZ contractors based on such contractors having a credential from an XYZ administrator. However, it is to be appreciated that altering the access rules for a resource can be cumbersome and burdensome, especially if such access rules must be continuously altered on an ongoing basis according to changes in access policy. Moreover, it is to be appreciated that altering the access rules for each of the many resources that can exist within a particular organization can easily become a gargantuan task.
Similarly, it may se the case that only some employees of ABC are normally allowed to access a given resource. Over time, there may be requirements to allow other employees temporary access to the resource. For example, an employee with authorized access may need to grant a subordinate temporary access while they are traveling. It could also be the case they wish to allow an assistant access so they may act on their behalf for certain business processes.
In the prior art, then, the ABC employees who don't normally have access to the resource would be given access to the resource in the same manner as the originally authorized employees. If this requires issuing new credentials, or setting new account attributes, the ABC administrator may be loathe to do so, especially if doing so could have the effect of granting the employees greater access rights than may be desired or requiring additional administrative actions be taken to remove such rights when the need for such access is no longer valid.
Thus, a need exists for a method and mechanism by which a resource can provide access to a requester not previously known thereto based on access rules or the like. In particular, a need exists for a method and mechanism by which the resource need only look to a defined source of trust, be it an administrator or the like, to determine whether access should be provided to a requestor. Further, a need exists for a method and mechanism by which the defined source of trust can identify whether a requestor is to be provided access, regardless of whether the requestor is internal to or external from the organization of the defined source of trust.